home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
p_misc
/
netconf.arc
/
UNIX.TXT
< prev
next >
Wrap
Text File
|
1988-12-10
|
45KB
|
905 lines
Packet Radio and IP for the Unix[1] Operating
System
Clifford Neuman, N1DMM
Wayne Yamamoto
Department of Computer Science
University of Washington
Seattle, WA 98195
_A_B_S_T_R_A_C_T
Many services are currently available on the ARPA
Internet that would be of interest to amateur packet
radio users. The ARPA Internet connects universities
and other organizations around the world that speak
TCP/IP. One advantage of running TCP/IP on packet
radio is the ability to access these services, and to
interconnect with other systems that are part of the
internet. This paper describes the implementation of
AX.25 as a link layer protocol for the Unix operating
system and the use of this system as an IP gateway
between our local amateur packet radio network and our
department's ethernet at the University of Washington,
which in turn provides access to the entire Internet.
The potential role of such a system for amateur packet
radio is discussed, and a mechanism to allow users
that don't have the resources to run TCP/IP themselves
to access such services is described.
_1. _I_n_t_r_o_d_u_c_t_i_o_n
In the past year, we have
started to see wider accep-
tance and use of layer three
protocols in amateur packet
radio. So far, most of this
activity has been by people
who are interested in advanc-
_________________________
[1] UNIX is a trademark
of AT&T
ing the state of amateur
packet radio. Many are people
who deal with computer net-
works outside of amateur
radio, and would like to see
similar facilities available
within packet radio. Others
have worked on mechanisms to
solve some of the problems
that amateur packet radio pro-
duced, and their solutions
have made a significant
difference in the way people
use packet radio in the parts
December 6, 1988
of the country where their
solutions are being tested.
In order to get more use
of layer three protocols by
the users instead of the
developers, there are two
requirements that should be
met. First, they need incen-
tive. There should be some-
thing that they can do using
layer three protocols that
they can't do using connection
[2] mode. One incentive is
the ability to access some of
the services available on more
established networks such as
the ARPA Internet. Among
these services are nameser-
vice, file transfer, access to
various databases, a more
flexible system for electronic
mail, and the ability to log
into hosts on connected net-
works. These services can be
made available in two ways.
Servers can exist directly on
amateur packet radio hosts, or
they can exist on other net-
works with a gateway set up
between the two networks. By
connecting our local packet
radio subnet to the internet,
it is possible to access files
on, and log into, computers at
other internet sites (or at
least, those where we have
accounts).
Secondly, we have to
lower the cost of entry. Most
packet users do not have IBM
PCs, or computers of
equivalent or greater power.
Many are simply using termi-
_________________________
[2] By ``connection''
mode we mean the existing
connection mechanism pro-
vided with TNCs when higher
level protocols are not be-
ing used.
nals connected to their TNC.
This is probably one of the
reasons that NET/ROM is so
popular. With a packet sta-
tion and no special hardware,
one is able to connect to a
NET/ROM node, connect to
another node through the net-
work, and come out the other
end. If we are to generate as
much interest in layer three
protocols such as TCP/IP, then
we must make it easy for con-
nection mode users to connect
to, and use, a system that
speaks IP. We can then point
out the advantages they would
have if their own system spoke
IP directly. Among these
advantages are the abilities
to exchange mail and transfer
files while simultaneously
connected to one or more other
systems.
_2. _S_y_s_t_e_m _O_v_e_r_v_i_e_w
We decided one way to
approach the above problems
would be to get a machine that
is on our department's ether-
net onto packet radio. We had
a MicroVax-I[3] available for
our use. The advantage of
using such a machine is that
it already supports many of
the network services that are
desirable in the packet radio
community. Among these are
electronic mail, remote login,
file transfer, and name ser-
vice. Although not presently
running on the machine, there
are other applications avail-
able too, such as NNTP[4]
which could be used as a bul-
_________________________
[3] MicroVax is a trade-
mark of Digital Equipment
Corporation
[4] Netnews Transfer Pro-
tocol
December 6, 1988
letin distribution mechanism.
The existence of such a
system gives users who have
brought up TCP/IP something to
connect to. The next step is
to give people who aren't yet
running TCP/IP something with
which they can connect. To do
this, we want to allow users
to connect to our system in
connection mode, and for them
to be able to login to our
system by this mechanism. The
only other service we want to
support in connection mode is
mail. We would like to be
able to exchange mail with
PBBSs, which don't speak
TCP/IP.
_3. _R_o_l_e _i_n _a _p_a_c_k_e_t _n_e_t_w_o_r_k
A machine such as the one
I described above serves
several functions in a packet
radio network. It functions
as a server for various net-
work services. It is useful
as a ``home'' machine for
those users who do not have
computers of their own. It
also can serve as a gateway
between multiple packet sub-
nets, and perhaps even non-
amateur networks. I have
already described its use as a
server. In this section I
describe its use in some of
these other functions.
_3._1. _H_o_m_e _m_a_c_h_i_n_e_s
For those users who don't
have IP running, our machine
can serve as a home machine.
Users can connect to it by
using connection mode. The
system can support multiple
connections of this type
simultaneously. When a user
is connected to our system, he
can use the various services
available to IP hosts. He
also will be allocated a lim-
ited amount of disk space, and
will be able to retrieve files
in which he is interested.
The mail interface the user
will be able to use presents a
better interface than the cen-
tral BBOARD mechanism which is
currently in use. The user
will be able to store messages
indefinitely as long as he
doesn't exceed his quota.
_3._2. _L_e_v_e_l _2 _t_o _L_e_v_e_l _3 _G_a_t_e_-
_w_a_y
Since the user can con-
nect to the system using con-
nection mode, and since the
system also speaks TCP, the
system serves as a Level 2 to
Level 3 gateway. Users will
not have to give up connec-
tivity with the old in order
to begin using the new.
_3._3. _I_P _G_a_t_e_w_a_y
A machine such as the one
described above is also a log-
ical machine to use as an IP
gateway, at least until such
time as we have dedicated
machines for such purposes.
Gatewaying could be between
multiple packet radio net-
works, and even between non-
radio networks such as the
ARPA Internet.
There are services avail-
able on the ARPA Internet that
are of interest to packet
radio users. If there is a
university in the area, it is
likely that there may be an
online database of upcoming
events. There are also many
mailing lists on the Internet
that might be of interest to
Amateurs.
Connecting to non-amateur
networks does bring up a
December 6, 1988
number of issues, such as
screening of messages in both
directions. I discuss solu-
tions to this problem later in
this paper.
_3._4. _N_E_T/_R_O_M
NET/ROM fits in nicely
with TCP/IP. IP can be run on
top of NET/ROM. In such an
arrangement, users on a LAN
would speak IP on top of
AX.25. Multiple LANs could
then be linked together using
NET/ROM. An IP gateway would
exist on each local area net-
work and would appear as a
NET/ROM node to other NET/ROM
stations. This arrangement is
similar to the way that local
area networks are linked by
the ARPAnet. NET/ROM nodes
correspond to the IMPs on net
10.
_4. _R_e_l_a_t_e_d _W_o_r_k
There has been a lot of
work recently in the TCP/IP
arena. Work has been done on
Phil Karn's IBM-PC code, and
it has been ported to other
machines such as the Amiga,
the Mac, and others. Steve
Ward and Mike Chepponis have
been working on additional
features in order to give
users greater incentive to
upgrade to TCP/IP.
Implementations of the
TCP/IP code are needed for
many more machines. Services
such as the ones I have
described also are needed for
these machines. Not many peo-
ple have access to a MicroVax
as I did. It is a good
machine to use in order to
determine how network users
react to such services. The
more machines such services
are available on, the more
people will be able to set
them up.
_5. _I_m_p_l_e_m_e_n_t_a_t_i_o_n
The Ultrix[5] kernel
already had all the code
necessary for Internet Proto-
col. Because we did not
modify the ``upper'' IP inter-
face, layers riding on top of
IP were able to use the packet
radio medium without modifica-
tion. Thus, TCP and UDP did
not need to be modified and,
similarly, applications run-
ning on top of those protocols
worked without modification.
The IP code in the kernel did
not require modification
either. All we had to do was
to find a way to take the IP
packets generated by the ker-
nel, encapsulate them in
AX.25 packets, and send them
off, using SLIP, to the KISS
interface of the TNC.
_5._1. _I_P _a_n_d _A_X._2_5 _a_n_d _t_h_e
_g_a_t_e_w_a_y
We chose to implement a
pseudo-device driver for the
packet radio interface. The
driver supports the same calls
as network device drivers do
for other media such as ether-
net. Our driver is a pseudo
driver because there is not
really any hardware on the bus
for our packet radio con-
troller. Instead, our con-
troller is plugged into a
dz[6] port, and the kernel
must communicate with it
through that port.
_________________________
[5] Ultrix is a trademark
of Digital Equipment Cor-
poration
[6] A controller for mul-
tiple RS-232 ports
December 6, 1988
Teaching the kernel to
recognize the new interface
was easy. There is a struc-
ture called if_net that is
associated with each inter-
face. This structure contains
pointers to the kernel pro-
cedures, which are used to
initialize the interface, send
a packet, change parameters,
and a few other operations.
The next trick was to figure
out how we could receive pack-
ets. This was done by includ-
ing a routine similar to the
one that gets called in the
ethernet driver when a packet
arrives. The difference,
though, is that our routine is
called by the dz driver when-
ever a character is received
on the line to which the TNC
is connected.
As each character is
read, we do some initial pro-
cessing on the fly. In par-
ticular, we unescape frame end
characters that are embedded
in the packet. When the final
frame end is read, we check
the header of the message,
note the callsigns, note the
layer three protocol type, and
if it is IP, we add the encap-
sulated IP packet to the queue
of incoming IP packets to be
dealt with by the existing
upper layers.
In order to implement the
routines described above, we
started with a few routines
from Phil Karn's code for the
IBM PC. These routines encap-
sulated and decapsulated AX.25
packets. With a few modifica-
tions these routines were made
to work in the Ultrix kernel.
The gateway functionality
came for free. The way an IP
gateway works is that when a
packet is received, the system
looks at its IP header to
determine the destination
address. If the destination
address is not its own, it
then decides which is the
correct destination interface,
and which system is the
correct next hop. This is all
done at the IP layer, and the
same code that existed for
gatewaying packets on ether-
nets works for AX.25 subnets
too.
_5._2. _A_d_d_r_e_s_s _R_e_s_o_l_u_t_i_o_n _P_r_o_-
_t_o_c_o_l
The final task was to
translate internet addresses
into AX.25 addresses. This is
done using ARP, the address
resolution protocol, in the
same manner that IP addresses
are translated into ethernet
addresses. But, AX.25
addresses look like amateur
radio callsigns followed by a
4 bit system ID. To make
matters worse, some entries
may contain additional
callsigns for digipeaters that
are to repeat the packet.
Thus, what is needed is a dif-
ferent set of ARP routines for
the packet radio interfaces.
Phil Karn's IBM-PC code
includes an ARP implementation
that supports both AX.25 and
ethernet addresses. Because
we did not want to modify the
code for our system that is
used on the ethernet side, we
decided not to take this code.
ARP lookup occurs at layer
two, and thus, gets called
inside either the ethernet
driver, or the AX.25 driver.
The routing tables at the IP
layer determine which driver
is called. Since the ARP
lookup occurs inside our code,
we are able to call a separate
routine that deals specifi-
cally with AX.25 addresses.
December 6, 1988
_5._3. _C_o_n_n_e_c_t_i_o_n _m_o_d_e
As already discussed, we
would like to support connec-
tion mode on our gateway.
Doing so would allow users who
do not have the resources to
run TCP/IP to be able to
access IP network services.
Further, users can give IP a
try, and if they like it, then
they might consider running it
themselves. However, there is
no reason, though, that con-
nection mode should be sup-
ported in the kernel as is IP.
The way our implementa-
tion is set up, it is easy to
allow user level process deal
with connection mode. We can
tell the kernel that if a
packet comes in, and its pro-
tocol ID is not IP, that the
packet should be placed on the
input queue for the appropri-
ate tty line. A user program
can then read packets that the
system isn't interested in
from that line, and deal with
the packets itself. By set-
ting appropriate parameters
for the kernel, additional
filtering could be provided,
though one would not want to
do anything too complex in the
kernel.
The user level process
that reads such packets would
have to keep track of any con-
nections and support connec-
tion mode itself. Such a pro-
gram could maintain multiple
connections, and direct input
to and output from pseudo ter-
minals. This would allow con-
nection mode users to log into
the system. Such a program
could accept connections to
multiple SSIDs, thus allowing
one SSID to be used for the
transfer of mail with local
non-IP bulletin boards.
_5._4. _O_t_h_e_r _l_a_y_e_r _3 _p_r_o_t_o_c_o_l_s
In addition to supporting
connection mode, support could
be provided in a similar
manner for other layer 3 pro-
tocols. I already mentioned
how NET/ROM can be used to
forward IP packets. One could
conceivably support the rest
of the NET/ROM interface in
the same manner as connection
mode is supported. Of course,
NET/ROM users would not have
the benefit of the additional
services available using IP.
_6. _U_n_r_e_s_o_l_v_e_d _i_s_s_u_e_s
The ability to intercon-
nect amateur packet radio net-
works and non-amateur networks
introduces a few problems
which have not been completely
resolved as of this time. In
this section, I present those
problems, and for some of
them, I suggest some possible
solutions.
_6._1. _T_i_m_e_o_u_t_s
One problem that comes up
is the difference in bandwidth
for the two networks. Hosts
on the ethernet side expect
fast response, and if they
don't get a response quickly,
they time out and retry their
transmission. We have found
that when connected to a sys-
tem on our department's ether-
net from a machine on the
packet side of the gateway,
the system on the ethernet
side initially retransmits
packets several times before a
response makes it back. This
results in wasted bandwidth on
the radio side as the packet
is needlessly retransmitted,
and this in turn delays other
packets. Fortunately for some
implementations of TCP, once
December 6, 1988
the connection has been esta-
blished, the system on the
ethernet side learns the
correct timeout, and things
settle down.
_6._2. _I_n_t_e_r_n_e_t _r_o_u_t_i_n_g
Routing is another prob-
lem that arises if we want to
allow connections to internet
hosts beyond our department's
ethernet. In order for a
response to come back, all the
gateways between the source
and the destination must know
the route to the appropriate
packet radio subnet. Since a
class `A' network is allocated
for AMPRnet, and since most
systems by default will main-
tain a single route for a
class `A' network, only one
path exists for all of
AMPRnet, whereas what is
desired is different gateways
for different subnets. It is
conceivable that something
like this could be handled
using ICMP[7] redirects, but
at this time, no mechanism is
in place.
_6._3. _A_c_c_e_s_s _C_o_n_t_r_o_l
Another problem we face
is access control. Since
operation is on frequencies
assigned to the amateur radio
service, any communication
must be initiated by licensed
amateurs. One way we can
solve this is to maintain a
table of authorized addresses
on the non-amateur side of the
gateway. Associated with each
of these addresses is a list
of hosts on the amateur side
of the gateway with which that
_________________________
[7] Internet Control Mes-
sage Protocol
host can communicate. Ini-
tially the table starts off
empty. Whenever a packet is
received on the amateur side
destined for a non-amateur
host, an entry is made in the
table, enabling the non-
amateur host to send packets
in the other direction. After
a certain period of time,
these entries time out if
packets have not been received
from the amateur side of the
gateway.
This scheme can be aug-
mented with a few new ICMP
messages. One message can
force an entry to be removed
from the table of authorized
non-amateur systems. This
allows the amateur radio
operator that initiated the
link to exercise his control
operator function to cut off
the link if he detects inap-
propriate use. Another mes-
sage would allow one to add an
authorized non-amateur host to
the tables with an appropriate
time to live. Both these mes-
sage are allowed to come from
either side of the gateway,
but if they come from the
non-amateur side, they must
include a call sign and a
password of for an authorized
control operator for the gate-
way.
_7. _S_t_a_t_u_s
The packet radio imple-
mentation of IP works. We
have successfully connected
from an IBM PC with a packet
radio controller to a machine
on our department's ethernet
using telnet.[8] The connec-
_________________________
[8] One of several remote
login protocols.
December 6, 1988
tion was made using our
MicroVax-I as a gateway. We
also were able to telnet from
the machine on the ethernet to
the PC.
In the Seattle area, we
are using a duplex repeater as
the base for our local area
network. Our network extends
from Seattle, south to Tacoma,
west to a station on the other
side of Puget sound, and east
to the Cascades.
We have not yet written
the user program to support
connection mode logins, but
that is being considered. We
also have not yet done any-
thing towards using NET/ROM to
interconnect our local area
networks with others, but we
would like to do that soon.
_8. _C_o_n_c_l_u_s_i_o_n_s
The Unix operating system
provides a nice base upon
which network services can be
provided for the amateur
packet radio community. At
the same time, such a system
can serve as a central node in
the interconnection of local
area networks running IP, and
even those that don't run IP.
By linking packet radio net-
works with more established
networks, additional services
become available. Such ser-
vices are available in the
Seattle area. These services
are necessary if we are to
interest people in running
TCP/IP. Further, interconnec-
tion with non-IP packet radio
users is necessary if we are
to interest users who would
like to try IP, but still want
to maintain connectivity with
those still using connection
mode.
_9. _A_c_k_n_o_w_l_e_d_g_m_e_n_t_s
A number of people were
helpful in getting our imple-
mentation running and in dis-
cussing some of the ideas
presented in this paper.
Among them are Bob Albrightson
(N7AKR), Bob Donnell (KD7NM),
Dennis Goodwin (KB7DZ), Mike
Chepponis (K3MC), Steve Ward
(W1GOH), and Ed Lazowska
(KG7K). Thanks are also in
order to Bob Hoffman (N3CVL)
for typesetting this paper.
_1_0. _B_i_b_l_i_o_g_r_a_p_h_y
1. Fox, Terry L.: AX.25 Ama-
teur Packet-Radio Link-
Layer Protocol. Version
2.0. American Radio
Relay league, October
1984.
2. Karn, Phil: ``TCP/IP, A
Proposal for Amateur
Packet Radio Levels 3 and
4'', _F_o_u_r_t_h _A_R_R_L _C_o_m_p_u_t_e_r
_N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e,
San Francisco, 1985.
3. Leffler, S; Joy W.; Fabry
R.; Karels M.: Networking
Implementation Notes 4.3
BSD Edition. Computer
Systems Research Group,
University of California,
Berkeley. June 1986.
December 6, 1988
